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INTRODUCTION 


This  report  contains  a copy  of  the  visual  aids  and  accompanying  narrative 
presented  at  the  American  Institute  of  Aeronautics  and  Astronautics  (AIAA) 
Conference,  Computers  in  Aerospace,  31  Oct-2  Nov  1977  at  the  International 
Hyatt  House,  Los  Angeles,  California.  The  presentation  was  part  of  a 
session  on  "Software  Management  - Development"  chaired  by  Mr.  James  P.  Chilton, 
McDonnell  Douglas  Astronautics  Company,  Huntington  Beach,  California. 

The  presentation  was  based  on  data  gathered  during  a survey  concerning  the 
U.S.  aerospace  industry’s  management  of  software  engineering  projects,  and 
represents  the  second  in  a planned  series  of  reports  on  the  data.  Report 
Nr.  1 is  contained  in  the  proceedings  of  the  subject  conference. 

The  survey  was  conducted  through  a rather  lengthy  questionnaire  concerning 
225  numbered  questions.  However,  through  the  use  of  question-packing 
techniques,  approximately  1,328  separate  responses  were  possible.  A subset 
of  the  survey  was  devoted  to  sampling  the  participants  to  determine  their 
feelings  about  specific  propositions  concerning  some  of  the  major  issues  in 
software  engineering  project  management,  the  degree  of  criticality  of  these 
issues,  whether  or  not  they  were  managerial  or  technical  problems,  and 
whether  or  not  solutions  could  be  effected  through  improvements  in  manage- 
ment or  technology.  The  survey  participants  were  also  asked  their  opinions 
on  how  they  did,  or  would,  solve  these  major  issues. 

In  all,  20  propositions  on  major  issues  of  software  engineering  project 
management  were  tested.  (See  Attachment  1 of  this  report)  Because  of  a 
limited  time  at  the  conference,  only  three  of  these  Issues  were  selected 
for  presentation  and  this  report  concerns  those  three.  (Propositions  1,  9, 
and  10)  The  propositions  as  presented  in  the  survey  were  rephrased  slightly 
for  the  conference  to  make  them  more  easily  understood. 
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THE  PRESENTATION 


A copy  of  the  visual  aids,  with  accompanying  narrative.  Is  provided  In 
Attachment  2.  The  narrative  Is  based  on  the  presentation  given  at  the 
conference.  In  those  Incidences  where  the  text  was  almost  Identical 
to  the  slide.  It  Is  not  repeated  and  the  slides  are  left  to  stand  on 
their  own. 


SUMMARY 


This  presentation  gives  a glimpse  Into  some  of  the  major  problems  of  soft- 
ware engineering  project  management,  the  feelings  of  project  managers 
concerning  these  problems,  and  whether  or  not  the  facts  and  data  gathered 
In  the  survey  support  their  beliefs  about  these  propositions.  Since  this 
survey  was  addressed  to  only  a small  sample  of  the  U.S.  aerospace  Industry, 
and  In  turn,  the  aerospace  Industry  represents  only  a portion  of  all  the 
organizations  In  the  United  States  doing  software  development.  It  could 
hardly  be  conclusively  stated  that  the  propositions  judged  true  In  our 
survey  are  true  In  all  cases.  However,  at  least  within  our  sample,  the  data 
bears  out  that  the  three  propositions  we  have  chosen  to  expound  upon  are 
Indeed  true. 
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ATTACHMENT  1 

MAJOR  PROBLEMS/MAJOR  ISSUES  OF  SOFTWARE 
ENGINEERING  PROJECT  MANAGEMENT 

INSTRUCTIONS. 

Four  answers  are  called  for  at  the  end  of  each  of  the  following  propositions. 
Chf.'k  one  word  or  phrase  to  complete  each  of  the  first  three  responses  and 
provide  a brief  narrative  in  response  to  Question  d. 

PROPOSITIONS. 

REQUIREMENTS  SPECIFICATIONS. 

1.  Problem  - Performance  specifications  are  frequently  Incomplete,  ambiguous, 
inconsistent,  machine  dependent,  and/or  unmeasurable. 

ANSWERS.* 

a.  This  problem  is: 

Critical  [ ] Not  Important 

Important  [ ] No  problem 

b.  This  is  a problem  in: 

Mar.agement  [ ] Both 

Technology  [ ] Neither 

c.  This  problem  can  be  solved  through  improvement  in: 

Management  [ ] Both 

Technology  [ ] Neither 

d.  How  would  (did)  you  solve  this  problem? 


[ ] 
[ ] 

[ ] 
[ 1 

[ ] 
[ ] 


* NOTE:  In  the  actual  survey  an  identical  set  of  choices  followed  each  of 
the  twenty  propositions. 
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SOFTWARE  DESIGN. 

2.  Problem  - There  are  no  decision  rules  for  the  software  engineering 
project  manager  to  use  In  selecting  the  correct  software  design  techniques 
or  tools  available  within  the  state-of-the-art. 

3.  Problem  - There  Is  no  measure  or  Index  of  "goodness"  of  code  that  can 
be  used  as  an  element  of  software  design,  and  there  Is  no  practical  way 
to  guaranty  one  program  Is  better  than  another. 

TESTING  AND  RELIABILITY. 
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4.  Problem  - There  are  no  decision  rules  for  selecting  the  procedures, 
strategies,  and  tools  to  be  used  In  testing  software. 

5.  Problem  - There  Is  no  measurement,  or  Index  of  reliability  that  can 
become  an  element  of  design  and  there  Is  no  way  to  predict  software 
failure;  l.e.,  there  Is  no  practical  way  to  guaranty  (prove)  the  delivered 
software  meets  a given  reliability  criteria. 

6.  Problem  - There  Is  no  way  to  guaranty  that  the  delivered  software 
meets  the  user's  requirements. 

MAINTENANCE  AND  MAINTAINABILITY. 

7.  Problem  - There  Is  no  measurement  or  Index  of  maintainability  that 
can  become  an  element  of  software  design;  l.e.,  there  Is  no  practical 
way  to  guaranty  that  a given  program  Is  more  maintainable  than  another. 

8.  Problem  - No  technical  discipline  exists  for  the  design  of  maintain- 
able programs. 

PROJECT  MANAGEMENT/ PLANNING. 

9.  Problem  - Planning  for  software  engineering  projects  Is  generally  poor. 

10.  Problem  - There  Is  an  Inability  to  accurately  estimate  delivery  time 
of  a computer  program. 

11.  Problem  - The  ability  to  plan  for  resources,  particularly  the  number 
of  programmers  required.  Is  poor. 

12.  Problem  - There  Is  no  real  quality  method  of  designing  a project  control 
plan  that  will  enable  project  managers  to  control  their  project. 

13.  Problem  - There  are  no  decision  rules  for  the  selection  of  management 
technlques  for  software  engineering  project  management. 
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PROJECT  MANAGEMENT/STAFFING. 

14.  Problem  - Techniques  for  the  selection  of  project  managers  are  poor, 
generally  resulting  In  poorly  managed  projects. 

15.  Problem  - There  Is  no  means  of  measuring  with  any  degree  of  accuracy 
the  quality  and  quantity  of  code  produced  by  a programmer. 


PROJECT  MANAGEMENT/ORGANIZATION. 

16.  Problem  - There  Is  a poor  accountability  structure  In  most  development 
projects,  leaving  some  question  as  to  who  Is  responsible  for  various  project 
functions. 

17.  Problem  - There  is  much  consternation  in  industry  concerning  how  best 
to  organize  for  the  accomplishment  of  a project  (e.g.,  should  the  project 

be  organized  around  the  function,  the  project,  or  under  a new  matrix  system?). 


PROJECT  MANAGEMENT/ CONTROL. 

18.  Problem  - It  is  difficult  to  impossible  for  a project  manager  to  have 
the  requisite  visibility  to  be  able  to  determine  whether  the  project  is  on 
schedule  and  within  cost. 

19.  Problem  - There  is  a general  lack  of  traceability  from  the  requirements 
specification  to  the  final  code. 

20.  Problem  - There  is,  in  general,  an  inability  to  measure  the  quality 
of  a program. 
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This  attachment  contains  a reproduction  of  the  visual  aid  (slides) 


I used  In  the  presentation. 

i 

Facing  each  slide  Is  the  narrative  that  accompanied  that  slide. 


SLIDE  NO.  1 


This  presentation  concerns  Software  Engineering  Project  Management; 
A State-of-the-Art  Report.  The  reference  to  "state-of-the-art"  is 
not  to  imply  a discussion  of  the  latest  concepts  in  project  manage- 
ment,  but  rather  how  software  engineering  projects  are  managed 
today  in  the  "real  world". 


SLIDE  NO.  2 

The  major  purpose  of  the  presentation  is  to  discuss  and  present 
the  results  of  a survey  on  how  the  U.S.  aerospace  Industry 
manages  its  software  engineering  projects. 
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THE  PURPOSE  OF  PAPER 

• TO  DISCUSS  AND  PRESENT  THE  RESULTS  OF  A SURVEY 
ON  HOW  THE  U.S.  AEROSPACE  INDUSTRY  MANAGES  ITS 
SOFTWARE  ENGINEERING  PROJECTS 


. 
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SLIDE  NO.  4 

In  creating  the  survey,  the  following  approach  was  taken.  A model  of 
a software  engineering  project  management  system  was  designed.  System 
elements  were  Identified  and  relationships  between  and  among  these 
elements  were  proposed.  This  model  formed  the  basis  of  the  question- 
naire, and  In  some  respects,  the  questionnaire  Itself  became  the  model. 
The  questionnaire  was  then  used  to  survey  that  segment  of  the  U.S. 
aerospace  Industry  comprising  the  membership  of  the  AIAA  Technical 
Committee  on  Computer  Systems,  the  conference  host.  The  committee 
membership  Is  comprised  of  senior  level  ADP  managers  In  many  of  the 
major  U.S.  corporations.  Individuals  In  an  ideal  position  to  respond. 

At  the  completion  of  the  survey  the  model  was  validated  and  a series 
of  reports  are  now  being  prepared.  This  presentation  Is  the  second 
In  this  series. 


THE  QUESTIONS 


• WHAT  ARE  THE  CURRENT  PRACTICES  IN  SOFTWARE  ENGINEERING 
PROJECT  MANAGEMENT  TODAY?? 

• ARE  THE  NEW  DEVELOPMENTS  IN  MANAGEMENT,  I.E.,  "MODERN" 
MANAGEMENT  TECH  OR  PROJECT  MANAGEMENT  TECH,  BEING  USED?? 

• WHAT  ARE  THE  TRENDS  IN  SOFTWARE  ENGINEERING  PROJECT 
MANAGEMENT?? 

• WHAT  ARE  THE  RELATIONSHIPS  BETWEEN  SOFTWARE  ENGINEERING 
PROJECT  MANAGEf’ENT  TECHNIQUES  AND  SUCCESSFUL  DELIVERY 
OF  SOFTWARE?? 

• WHAT  ARE  THE  RELATIONSHIPS  BETWEEN  VARIOUS  ELEMENTS 

OF  SOFTWARE  ENGINEERING  PROJECT  MANAGEMENT  AS  A SYSTEM?? 

• WHAT  ARE  THE  RELATIONSHIPS  BETWEEN  "MODERN"  SOFTWARE 
ENGINEERING  TECHNIQUES  AND  SOFTWARE  ENGINEERING  PROJECT 
MANAGEMENT?? 


# A 


THE  APPROACH  TO  ANSWERING  THE  QUESTIONS 


1.  DESIGN  A MODEL  OF  SOFTWARE  ENGINEERING  PROJECT  MANAGEMENT 
AS  A SYSTEM  DEFINING  ELEMENT  AND  PROPOSING  RELATIONSHIPS 
AND  FORM  QUESTIONNAIRE  AROUND  MODEL. 


2.  SURVEY  A SAMPLE  OF  U.S.  AEROSPACE  INDUSTRY  AS  REPRESENTED 
BY  MEMBERSHIP  ON  THE  AIAA  TECHNICAL  COMMITTEE  ON  COMPUTER 
SYSTEMS. 


3.  VALIDATE  THE  MODEL. 


A.  REPORT  THE  RESULTS. 
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SLIDE  NO.  5 


All  the  returns  are  not  yet  In.  Thirty-three  companies,  representing 
70%  of  the  total  mailing  reporting  on  fifty- two  projects,  have 
responded.  Large  to  very  large  projects  developed  under  government 
contract  predominate. 


SLIDE  NO.  6 

As  previously  stated.  Part  Three  of  the  questionnaire  contained 
propositions  (twenty  In  all)  concerning  problems  and/or  major  Issues 
In  the  area  of  software  engineering  project  management.  This 
presentation  discusses  three  of  these  propositions  and  the 
respondent's  position  relative  to  them.  The  answers  to  Part  Two 
of  the  survey  (the  individual  project  reports)  are  then  compared 
to  the  responses  to  Part  Three  to  determine  whether  or  not  the 
data  submitted  In  Part  Two  supports  the  contentions  of  Part  Three. 
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THE  SURVEY 


33  COMPANIES  (70%  RETURNS)  ANSWERED  1338  QUESTIONS 
(72  PAGES)  ABOUT  HOW  THEY  OR  THEIR  COMPANY  MANAGE 
SOFTWARE  ENGINEERING  PROJECTS. 


52  PROJECTS  WERE  REPORTED  ON. 


COMPANIES  WERE  PREDOMINANTELY  AEROSPACE  FIRMS,  WITH 
GOVERNMENT  CONTRACTS,  REPORTING  ON  LARGE  TO  VERY 
LARGE  PROJECTS. 
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PROPOSITION  (ABOUT  PROBLEMS)  TO  BE  TESTED 


• PROPOSITION  1:  REQUIREMENT  SPECIFICATIONS  ARE  FREQUENTLY 
INCOMPLETE,  AMBIGUOUS,  INCONSISTENT,  AND/OR  UNMEASURABLE 


• PROPOSITION  9:  PLANNING  FOR  SOFTWARE  ENGINEERING  IS 
GENERALLY  POOR 


• PROPOSITION  10:  THE  ABILITY  TO  ACCURATELY  ESTIMATE  DELIVERY 
TIME  ON  A SOFTWARE  DEVELOPMENT  IS  POOR 
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SLIDE  NO.  7 


As  we  discuss  each  of  these  propositions,  you  may  want  to  ask  yourself: 
Does  the  proposition  reflect  a problem  that  Is  critical.  Important, 
not  very  Important,  or  no  problem  at  all?  If  this  Is  considered  a 
problem  of  some  magnitude,  is  It  a problem  In < management,  technology, 
both,  or  neither?  And,  If  this  Is  recognized  as  a problem.  Is  It 
amenable  to  solution  through  Improvements  In  management,  technology, 
both,  or  neither? 


SLIDE  NO.  8 ! 

j 

Proposition  1 pertains  to  an  often  heard  complaint  about  requirements: 
"Requirements  specifications  are  frequently  Incomplete,  ainblguous. 

Inconsistent  and/or  unmeasurable."  Is  this  proposition  true?  What 
^ type  of  problem  Is  It?  And,  how  could  It  be  solved? 
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IS  THIS  PROPOSITION  (PROBLEM): 

CRITICAL  ? NOT  IMPORTANT  ? 

IMPORTANT  ? NO  PROBLEM  ? 


THIS  IS  A PROBLEM  IN; 

MANAGEMENT  ? BOTH  ? 

TECHNOLOGY  ? NEITHER  ? 

THIS  PROBLEM  CAN  BE  SOLVED  THROUGH  IMPROVEMENT  IN; 


MANAGEMENT  ? BOTH  ? 

TECHNOLOGY  ? NEITHER  ? 


SACRAMENTO 


PROPOSITION  1 


REQUIREMENT  SPECIFICATIONS  ARE  FREQUENTLY 
INCOMPLETE,  AMBIGUOUS,  INCONSISTENT,  AND/OR 
UNMEASURABLE. 


i 
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SLIDE  NO.  9 


( According  to  the  survey  in  which  45  project  managers  reported,  96% 

said  the  problem  was  at  least  Important.  (It  should  be  pointed  out 
at  this  time  that  these  propositions  were  not  placed  In  any  rank 
I order  by  the  authors;  however.  Propositions  1,  9 and  10  represent 

the  three  most  critical  problems  In  the  opinion  of  the  surveyees.) 
The  majority  of  the  people  felt  that  the  propositions  were  a 
problem  In  both  management  and  technology,  though  a nu]id>er  felt 
It  to  be  a problem  In  management  alone.  The  same  number  felt  It 
could  be  solved  either  by  management  and  technology,  or  management 
alone. 


SLIDE  NO.  10 

In  looking  at  the  results  of  the  survey.  It  was  determined  that  67% 
of  the  project  managers  thought  It  necessary  to  rewrite  specifications 
before  proceeding  with  the  design.  Of  these,  an  43%  average  rewrite 
was  required.  The  reasons  given  were  (33  reported):  errors,  24%; 
Incompleteness  or  ambiguity,  33%;  change  In  scope  27%;  change  In 
requirements,  24%;  either  the  customer  or  the  developer  became 
smarter,  21%.  Two  Individuals  felt  that  changing  requirements  were 
the  normal  order  of  things. 

In  summary,  we  can  conclude  that  the  vast  majority  of  project  managers 
surveyed  felt  the  requirements  specifications  as  original^ presented 
Indeed  present  a serious  problem.  The  results  of  the  Individual 
project  surveys  bear  this  out. 
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SURVEY  RESULTS 


67X  OF  PROJECT  MANAGERS  FOUND  IT  NECESSARY  TO  REWRITE  SPECIFICATIONS 
BEFORE  PROCEEDING  WITH  DESIGN  (51  RPT) 


OF  THESE,  i|3%  (RANGE  15  TO  lOOX)  OF  THE  REQUIREMENT 
SPECIFICATIONS  WERE  REWRITTEN  (32  RPT). 


REASON  FOR  REWRITING  (33  RPT): 


ERRORS 

24Z 

SMARTER 

21X 

AMBIGUOUS/ INCOMPLETE 

33Z 

NORMAL 

6X 

CHANGES  IN  SCOPE 

271 

OTHER 

3X 

CHANGES  IN  REQUIREMENTS 

2« 

J 
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SLIDE  NO.  11 


At  this  point  you  may  wish  to  compare  your  attitudes  and  experience 
with  the  survey  respondents  In  answering:  Does  the  proposition 
reflect  a problem  that  Is  critical.  Important,  not  very  Important, 
or  no  problem  at  all?  If  this  Is  considered  a problem  of  some 
magnitude.  Is  It  a problem  In  management,  technology,  both,  or 
neither?  And,  If  this  Is  recognized  as  a problem.  Is  It  amenable 
to  solution  through  Improvements  In  management,  technology,  both, 
or  neither? 


SLIDE  NO.  12 

Looking  at  the  survey  results,  of  the  44  project  managers  that  reported, 
91%  of  them  felt  that  the  problem  was  at  least  Important.  Only  9%  felt 
It  to  be  unliiq>ortant  or  no  problem  at  all.  Seventy-three  percent  felt 
that  It  was  a problem  In  management,  while  68%  felt  It  could  be 
solved  through  Improvements  In  management,  and  another  27%  thinking 
It  would  take  both  management  and  technology  to  do  the  trick. 
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PROPOSITION  9 


PLANNING  FOR  SOFTWARE  ENGINEERING  PROJECTS  IS 
GENERALLY  POOR. 


PROPOSITION  9:  PLANNING  FOR  SOFTWARE  ENGINEERING  PROJECTS 
IS  GENERALLY  POOR. 


SURVEY  OPINIONS  (4A  RPT),  VALUES  IN  X: 

PROBLEM  IS:  PROBLEM  IN:  SOLVED  BY: 

r 


2 


7 


SLIDE  NO.  13 


Before  proceeding  to  determine  whether  or  not  the  project  data  bears 
out  both  the  proposition  and  beliefs  of  the  project  managers.  It 
might  be  well  to  provide  our  definition  of  planning,  which:  deciding 
In  advance  what  to  do,  how  to  do  It,  when  to  do  It,  and  who  Is  to  do  It  I 
This  Is  not  original  definition,  having  come  from  Principles  of  Manage- 
ment: An  Analysis  of  Managerial  Functions  by  Kootz  and  O'Donnell  [1972] 
Good  planning,  as  defined  by  the  author.  Involves  planning  for  all 
functions  (sufficient  breadth).  In  sufficient  detail  (depth),  and  with 
sufficient  accuracy.  In  contrast,  poor  planning  Is  limited  to  scope, 
shallow  and  Inaccurate. 


SLIDE  NO.  14 

By  way  of  background,  22%  of  the  projects  used  a special  planning 
group  for  planning,  and  only  12%  of  the  managers  had  a formal  planning 
guide  furnished  either  by  the  company  or  some  other  outside  organization 
Of  the  planning  tools  that  were  used,  GANTT  charts  and  workload  charts 
were  by  far  the  most  popular. 


#13 


DEFINITION  PLANNING 


PLANNING  IS  DECIDING  IN  ADVANCE  WHAT  TO  DO.  HOW  TO  DO  IT. 
WHEN  TO  DO  IT  AND  WHO  IS  TO  DO  IT. 


GOOD  PLANNING  INVOLVES  PLANNING  FOR  ALL  FUNCTIONS.  IN 
SUFFICIENT  DETAIL  AND  WITH  SUFFICIENT  ACCURACY. 


POOR  PLANNING-  IS  LIMITED  IN  SCOPE.  SHALLOW  AND  INACCURATE 
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SURVEY  RESULTS 

221  OF  THE  PROJECTS  USED  A SPECIAL  PLANNING  GROUP  FOR  PLANNING  (50  RPT) 
12Z  OF  THE  MANAGERS  USED  A FORMAL  PLANNING  GUIDE  (A9  RPT) 

THE  FOLLOWING  PLANNING  TOOLS  WERE  USED  (45  RPT) 


PERT 

7Z 

WORKLOAD 

65Z 

MODIFIED  PERT 

13X 

MILESTONE 

4Z 

CPM 

4Z 

OTHER 

20Z 

GANTT 

36Z 

NONE 

6Z 
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SLIDE  NO.  15 


Though  perhaps  not  the  ultimate  measure  of  breadth  of  planning, 
this  chart  does  show  the  functions  planned  for  and  provides  the 
breakdown,  by  percent,  of  time  spent  on  each. 

i 
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SLIDE  NO.  16 

As  a measure  of  depth,  we  referred  to  the  scope  and  variety  of 
planning  documents  employed,  and  the  list  Is  fairly  Impressive. 


I 
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SURVEY  RESULTS 


it  15 


15X  (RANGE  3 TO  85X)  OF  THE  PROJECTS  TIME  WAS  SPENT  PLANNING  (A2  RPT) 
PLANNING  ALLOCATlD  TO  (36  RPT)'- 

RANGE  AVERAGE 

MANAGEMENT  10-752  232 

ORGANIZATIONS  5-502  152 

STAFF  1-602  192 

CONTROL  PROCEDURES  4-602  192 

ADMINISTRATION  5-302  92 

QUALITY  ASSURANCE  2-302  122 

OTHER  5-352  52 
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SURVEY  RESULTS 

THE  FOLLOWING  PLANNING  DOCUMENTS  WERE  PREPARED  (50  RPT) 
DOCUMENT  PCT  USED 

SOFTWARE  DEVELOPMENT  76 

CHANGE  CONTROL  70 

TEST  68 

DOCUMENTATION  60 

ORGANIZATION  56 

STAFFING  52 

REVIEW  AND  REPORTING  50 

RESOURCE  REQUIREMENTS  50 

PROJECT  MANAGEMENT  50 

PHASE  AND/OR  DELIVERY  46 

IMPLEMENTATION  36 

TRAINING  24 

DATA  CONVERSION  6 

PRODUCT  ASSURANCE  2 

CONFIGURATION  MANAGEMENT  2 

WORK  BREAK  DOWN  STRUCTURE  2 

BUDGET  2 

NONE  4 


23 


SLIDE  NO.  17 
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Breadth  and  depth  do  not  necessarily  add  up  to  accuracy.  Forty-seven 
percent  of  the  projects  were,  or  were  expected  to  be,  delivered  late. 

Of  these,  37%  cited  poor  planning  as  a contributing  factor.  Fifty- 
three  percent  of  the  projects  were,  or  were  expected  to  be,  delivered 
over  cost.  Of  these,  41%  cited  poor  planning  as  a contributing  factor. 
In  answer  to  one  of  the  questions  in  Part  Two  of  the  survey,  32%  of 
19  projects  responding  cited  the  need  for  improved  planning  as  a 
lesson  learned,  while  39%  cited  planning  as  a function  they  wanted 
to  see  Improved. 

The  project  managers  surveyed  believed  Proposition  9 to  be  true,  and 
the  results  of  the  survey  appear  to  bear  this  out. 


SLIDE  NO.  18 

Would  you  like  to  compare  your  findings  with  those  of  the  experts? 
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SURVEY  RESULTS 

m OF  THE  PROJECTS  WERE,  OR  EXPECT  TO  BE,  DELIVERED  LATE  (U7  RPT) 

37Z  CITED  POOR  PLANNING  AS  A CONTRIBUTING  FACTOR  (23  RPT) 

53X  OF  THE  PROJECTS  WERE,  OR  EXPECT  TO  BE,  DELIVERED  OVER  COST  (45  RPT) 
41%  CITED  POOR  PLANNING  AS  A CONTRIBUTING  FACTOR  (17  RPT) 

32Z  CITED  "IMPROVED  PLANNING"  UNDER  LESSONS  LEARNED  (19  RPT) 

392  CITED  PLANNING  AS  A FUNCTION  THEY  WANTED  TO  SEE  IMPROVED  (28  RPT) 
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SACRAMENTO 


PROPOSITION  10 

THE  ABILITY  TO  ACCURATELY  ESTI'IATE  DELIVERY  TIME 
ON  A SOFTWARE  DEVELOPMENT  IS  POOR. 


SLIDE  NO.  19 


The  project  managers  surveyed  concurred  with  this  proposition  with 
96%  feeling  this  proposition  was  at  least  Important.  As  to  just 
what  type  of  problem  this  was,  opinion  divided  almost  evenly 
between  exclusively  a management  problem,  and  both  a management 
and  technological  problem. 


SLIDE  NO.  20 

A quick  tally  on  this  slide  gives  you  166%,  which  only  means  that 
some  projects  employed  more  than  one  estimating  technique.  Intuition 
appears  to  rank  high,  for  though  "knack"  at  12%  must  be  purely 
intuitive,  few  of  the  other  procedures  stray  too  far  from  that 
educated  guess. 
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PROPOSITION  10=  THE  ABILITY  TO  ACCURATELY  ESTIMATE  DELIVERY  TIME 
ON  A SOFTWARE  DEVELOPMENT  IS  POOR. 


SURVEY  OPINIONS  (42  RPT),  VALUE  IN  X: 


PROBLEM  IS:  PROBLEM  IN:  SOLVED  BY: 
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SURVEY  RESULTS 

THE  FOLLOWING  METHODS  WERE  USED  IN  ESTIMATED  COST  AND  SCHEDULE 
FOR  THE  PROJECT  (50  RPT) 

ESTIMATE  BASED  ON  SIMILAR  PROJECT 

66Z 

FORMULA 

42X 

COST  AND/OR  SCHEDULE  DICTATED 

201 

ESTIMATED  BY  SOMEBODY  WHO  HAS  A KNACK  FOR 
ESTIMATING  CORRECTLY 

12Z 

CRYSTAL  BALL  (OR  SIMILAR  MEANS) 

122 

BOTTOM  UP 

22 

OTHER 

122 
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SLIDE  NO.  21 


This  slide  lists  the  factors  that  went  Into  determining  costs  and 
schedule.  They  ranged  from  program  complexity,  57%,  down  to  key- 
punch, 17%.  Lines  of  code  were  used  by  26%.  However,  through  an 
oversight,  lines  of  code  were  not  specifically  listed  as  a selection 
requiring  a written  response.  We  believe  that  if  lines  of  code 
had  been  an  easily  selected  response,  the  figure  would  have  been 
higher . 


SLIDE  NO.  22 

As  previously  stated,  47%  of  the  projects  were  delivered  late. 
Whether  or  not  the  project  was  delivered  late  or  on  time,  it  was 
compared  to  the  evaluation  technique.  This  slide  Indicates  with 
reasonable  accuracy  that  it  does  not  matter  what  type  of  technique 
you  use  in  estimating  delivery  schedule,  the  chance  of  being 
delivered  on  time  or  late  is  approximately  the  same;  leaving  ua  to 
conclude  that  the  data  does  bear  out  that  the  ability  to  accurately 
estimate  delivery  time  on  software  development  is  poor. 
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SURVEY  RESULTS 
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IN  DETERMINING  COST  AND  SCHEDULE,  THE  FOLLOWING  ELEMENTS 
WERE  CONSIDERED  (35  RPT): 


PROGRAM  COMPLEXITY 

57Z 

DOCUMENTATION 

SIX 

NUMBER  OF  MODULES 

46Z 

COMPUTER  TIME 

37X 

PROGRAMMER  PROFICIENCY 

3AX 

RATIO  OF  OVERHEAD  TO  PROGRAMMERS 

31X 

LINES  OF  CODE 

26Z 

FACILITIES,  SUPPLIES,  EQUIPMENT 

26X 

TRAVEL 

26X 

TRAINING 

23Z 

TESTER  PROFICIENCY 

20Z 

KEYPUNCH 

17Z 

OTHER 

20X 

NONE 

31X 
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SURVEY  RESULTS 

^7l  OF  THE  PROJECTS  WERE  DELIVERED  LATE  (A7  RPT) 
EVALUATION  OF  TECHNIQUE  USED 


TECHNIQUE 

DEL  ON  TIME 

DEL  LATE 

ESTIMATE  BASED  ON  SIMILAR  PROJECT  (30  RPT) 

53Z 

A7Z 

FORMULA  (19  RPT) 

58Z 

^2l 

COST  AND/OR  SCHEDULED  DICTATED  (9  RPT) 

33Z 

67Z 

ESTIMATE  BY  SOMEBODY  WITH  KNACK  (7  RPT) 

57X 

93X 

CRYSTAL  BALL  (5  RPT) 

90Z 

60Z 

LINES  OF  CODE  (9  RPT) 

67Z 

33Z 

PROGRAM  COMPLEXITY  (19  RPT) 

53Z 

47Z 

NUMBER  OF  MODULES  (15  RPT) 

53X 

PROGRAMMER  PROFICIENCY  (11  RPT) 

36Z 

64Z 
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